Regional pricing exploit (Klonan) Earlier this week I received an unusual number of support emails, some players were having trouble redeeming their Steam keys on our website. In each case, the key they purchased was not a key eligible for a Steam key. Our order/account system isn't the most intuitive, so let me explain the ways in which people can buy the game, and how it relates to our website: Our website - You buy from our website, and you get a key from the Humble checkout. You use this key to upgrade an account, and you can redeem a Steam key. Steam - You buy on Steam, which adds it to your Steam account. You then link your Steam on our website, which upgrades your account. Humble Store - You buy a Steam key, which you activate on Steam, and then follow the steps above. GOG - You buy the game on GOG, which lets you download the DRM free version. You can also redeem a retail key, to upgrade your account. So in the cases above, the only way to get a Steam key from our website, is by buying directly on our website. The players in question managed to get their hands on 3rd party retail keys. These retail keys aren't distributed for reselling anywhere, so the fact I was seeing a lot of emails coming in about these keys, was an indication something fishy was going on. The source of these keys is GOG, I double checked this my comparing some of the keys these people purchased with the list of keys we generated for GOG, and they matched. My first suspicion was someone cheesing the GOG return policy, buying the game, redeeming the key, and then refunding it. I emailed our contact and there were only 21 refunds in the last 3 months, so it was not the case. The second suspicion was that the GOG server was breached somehow. They reported no incident, but we disabled all the unredeemed keys anyway just to be sure. I checked with the list again, and none of the keys that we deactivated were used by any account. This led to the conclusion, at the very least, these keys were purchased legitimately. So people are legitimately buying keys, GOG confirmed sales had shot up in the last week. Then the question, where are the sales coming from? One last email to GOG and we had our answer: Russian Federation. The reason? We have regional pricing on GOG at parity with Steam, which means someone buying from Russia could buy the game for ~$8.30. Once they buy on GOG, they can redeem the retail key, and sell it for about $20 on a 3rd party site. So one clever guy saw this opportunity, and started buying the game hundreds of times on GOG. The immediate solution is to remove the regional pricing, and in the long term we may be able to implement some 'GOG linking' similar to the current system for Steam users. It is strange that it was only taken advantage of recently, as we have had regional pricing since our launch on GOG 2 years ago. It may be related to the recent price increase.
Ok→Cancel versus Cancel→Ok (kovarex) A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around. But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed: Eventually, we figured out, that we are not the first one trying to solve the problem. The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:
New Python developer (Klonan) Mobile users may see that the website is significantly easier to read today, that is all thanks to our new Python developer Sanqui. Apart from making our website more mobile friendly, we have a lot of tasks on the backlog that he will start working on soon. His first major task is to speed up and optimize the matching server, with which he is already making some progress. A bigger rewrite for the long term is underway, but in the last week he has reduced a lot of the slowness and timeouts people were seeing during peak times. He will be taking over our database management and web administration from HanziQ, as well as spending time cleaning up our codebase, maintaining our web services, and developing features for the mod portal.
The new GUI tileset (Albert) The process of the GUI re-design is moving slowly but steadily. By making new mockups, re-thinking old mechanics, and with the proper feedback from a different range of people, the parts are falling into place. I'm starting to feel very confident with the actual general contrast and font sizes. Also the conversion from high resolution to normal resolution is working just fine. These subjects are very important to move forward with. Below you can see a demo of the current state of the new GUI. Not all the widgets are shown yet, but this document is helping us a lot in order to define the future elements. Seeing the big picture makes it much easier to tweak them altogether with a better coherence and consistency, not to mention for testing any kind of font, specifically non-latin characters sets, a subject that I personally have not paid too much attention to yet. This document is being used also to create the general tileset and see how it behaves in the engine. This is a work in progress, and we are tweaking details constantly. Many things will change during the process. Overall here you can see a sneak peek of the Factorio GUI to come. I want to also mention that we are actually taking care of the 8% of the population who has some sort of color vision problems. This subject is still very new for us, but we are without a doubt researching solutions to different conditions.
Hello, this post is going to be more technical than usual, yet it might still be interesting to know the background of the process for some people.
The GUI update (Part II) - Technology tree Today we will speak a bit about the work in progress of the Technology tree, and the main GUI style/philosophy evolution. The visual style is evolving and becoming more mature. The aim is to be as functional as possible, and also be pleasant to interact with, always having in mind the limitations of making it work in our engine. This is why we bet for a neutral and sober look that helps to focus on the relevant elements, without the distraction of possible decorative elements. This is not easy to decide, because the tradition of video-games is very rich in decorative GUI elements, and I'm sure that many of you would prefer having screws and rust in the corners of the metal panels and cables hanging everywhere in the GUI. Me too. Sometimes. I believe that once the GUI is completely functional, there will be some minimal decoration and this kind of fantasy, but this will be another chapter if it ever happens. We are paying a lot of attention to the readability in general, according to the AAA standards of the WCAG. So the contrast with the panels and the font is increased quite a lot compared to previous mock-ups by simply using a contrast checker. Also the font size is increased by 2pt so it is more comfortable to read. Anyway, the user will have control of the font size in the options menu. Bear in mind that the next mock-ups are a work in progress, and we still developing our standards, so some colours and solutions can vary through further iterations.
Hello, since 0.16 is stable we can assign more of our effort into the work on 0.17. One of those features planned for that release is the Rich & interactive text. Having more text formatting options was one of the things we wanted for quite some time, and it is finally starting to become reality in the 0.17 branch. The initial motivation was to have more possibilities in the tutorial related texts, but it proved to be useful having it available globally in the game. The current format for any text markup we use is [<type>=<value>], but it might change somehow before 0.17 hits the public. This feature is being developed by wheybags, and it is progressing forward quite steadily.
0.16 to be declared stable Rseding thinks that we have the least amount of bugs in the game we ever had. Mostly because of the automated reporting system and partly because of my pushing of everyone to fix everything before starting other tasks. The 0.16.35 (to be released soon) will be declared stable on Monday, if no critical problems are discovered. This naturally leads us to:
Belt compression (kovarex) The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities: Splitters are the only way to reliably compress a belt. Compression is automatic everywhere (inserters, sideloading, mining drills). Non-automatic belt compression is kind of an nice example of emergent gameplay mechanic that I liked. It was not forced on players, but it allowed to get some extra efficiency if they cared enough. On other hand, the solution to the problem is kind of obvious, and having to use it in all the setups everywhere might add more repetitiveness than fun. So after some discussions, we decided to make compression automatic. But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it: The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now. The result is, that the same setup in 0.16.25+ results in perfectly compressed belt: The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result.
